Имеем порядка 10 Lon устройств (SC-LGW-AR - 3шт., GOLD - 5шт., еще осушитель от Dantherm, чиллер) устройства расмологаются в разных частях здания и соединены все шиной на обоих концах шины стоят терминаторы (R=120 Ом). В качестве переобразователя интерфейсов используется iLon10, к клеммам которого и подключено одно из выше упомянутых сопротивлений, а также шина от других устройств.

В качестве конфигуратора Lon сети и LNS базы данных используется NL220TE; OPC сервер - NLopcTE тогоже производителя (Newron Systems).
Суммарное общее количество переменных этих устройст соствляет порядка 16- 18 тыс. переменных. Общее количество необходимых нам и опрашиваемых нами переменных составляет 5 тыс. (+/- 500) переменных.

После того как стартует проект в SCADA системе, запускается OPC сервер, иницилизуруются переменные, и начинается первый опрос. Первое что начинает смущать это скорость опроса порядка 10-15 переменных/сек. Спустя некоторое время (это может быть сразу, а может быть спустя 5-10 минут или через 30 минут) в логе ОРС сервера начинают проскакивать записи об ошибках чтения: "Error reading network variable : Network Variable Read failed. (Subsystem: Data Server, #410)" и "Error fetch nv (no response) : <16May_LGW.Locations.GOLD - PV4.nvoSetpoint>" ошибки могут повторяться некоторое время для разных переменных различных устройств, могут пропасть на некоторое время и те переменные что не читались могут прочитаться, но через некоторое время появляются ошибки для каждого из устройств сети "Error getting network status (no response) : <16May_LGW.Locations.GOLD - PV4>" После этотих ошибок возврат в нормальное состояние уже не происходит, т.е. все переменные плохого качества, устройства не отвечают, а при каждой попытке перезапуска опроса ОРС сервером выдается все таже ошибка, что устройство(-а) не отвечает(-ют) (Error getting network status (no response) : <"путь к устройству">).

Запускали опрос с малым количеством переменных (500) и только одного устройства подсоединенного на прямую (без сети остальных устройств) Ситуация немного лучше т.е. ошибки возникают реже, но все же возникают, и не происходит такого ступора когда устройство не отвечает. Бывает что все переменные плохого качества, но связь с устройством востаннавливается и опрос продолжается в обычном режиме.

Запускали опрос нескольких устройств сети и опрашивали всего 250 переменных происходит нормальный опрос, потом начинают возникать ошибки, спустя некоторое времени устройства снова не отвечают и не выходят из этого состояния.

В чем может быть проблема? Кто-нибудь сталкивался с подобной ситуацией?

Может вам стоит посмотреть сетевой обмен лонсканнером.

Проблема скорее всего в сети. Терминаторы 120 ом - это от RS-485. У лона другие.
Еще могут быть наводки от частотников, от силовых проводников.
Нужно смотреть лон анализатором что творится в сети.

"Суммарное общее количество переменных этих устройст соствляет порядка 16- 18 тыс. переменных. Общее количество необходимых нам и опрашиваемых нами переменных составляет 5 тыс. (+/- 500) переменных." - Вы ничего не путаете? Банальный осушитель 500 переменных??, чиллер тоже 500?

1. физика :про теРРминаторы писал как-то раз Здесь

2. физика : километраж, тип кабеля?

3. IMHO :снизить время допроса переменных, установленное по умолчанию, со стороны SCADA (о чем тоже где-то в ветке Форума уже писалось)

некоторые устройства тупеют под шквалом запросов и/или когда счетчик ошибок в максимуме (из практики: лечится с помощью Reset со стороны LON и Cold Restart на всякий случай)

Ну и Диагностика нагрузки LON сети, как уже написали Коллеги.

О результатах не постесняйтесь рассказать
--
Успехов!

предположим, что SNVT_state_64 разложили по битам, обзывают как они видют со стороны OPC переменными вместо OPC DataPoint и дергают каждый бит по default time из LONа ?

Автора в студию. Чего на ромашках гадать?

Пытались посмотреть что творится в сети ЛонСканером, но так и не удалось разобраться с ним. Плюс ко всему на сколько я понял с iLon10 не получится подключиться одновременно скнером и запустить опрос переменных с ОРС сервера.



"+/- 500 переменных" это имелось ввиду то, что на момент написания было 4800 лон переменных, в процессе оптимизации и удлении из списка опрашиваемых дублирующих друг друга переменных, а также не используемых, сейчас общее количество сократилось до 4400 переменных, однако в дальнейшем добавятся несколько переменных с чиллера, и возможно возрастет количество необходимых переменных с GOLD'ов, потому таким образом и загрубил "плюс минус лапоть".



1. Про термитаторры, спасибо, попробуем поставить, те что рекомендовали.
2. Что касается кабеля то от основная часть устройств (те что находятся далеко от диспетчерской ) соединены экранированным 3-ех жильным МКЭШ (третья жила никак не используется), земля прикручена в только в диспетчерском шкафу в котором и установленны 3 шлюза SC-LGW-AR. Устройства условно можно поделить на 3 группы, по тому в какой венткамере они установленны. В диспетчерский шкаф от каждой группы устройств приходит два конца проводов (от первого устройства группы и последнего устройства группы). Соединение сегментов сети в последовательную шину происходит собственно в шкафу через клеммы (сверху приходящие концы всех групп, снизу провода-перемычки: медный многожильный провод 0,75). Шлюзы (условно можно назвать четвертой группой устройств) соеденены темже многожильным проводом (как и перемычки) в самом шкафу (2 конца обжатые вместе продключены к шлюзам). Один конец четвертой группы идет к в нижнюю часть тех клемм где объеденены остальные устройства, а другой к оконечному устройству - iLon10.
3. Временем опроса конечно игрались причем доходило до того что период опроса был равен 1часу, но даже первый опрос всех переменных не проходил без ишибочно, и сеть (устройства) ложилась (-ись) на 2-4 опросе.


Хотелось бы поподробнее узнать каким образом можно диагностировать данную сеть ЛонСканером или другой программулиной с учетом того что у нас iLon10, а не iLon100. Возможен ли такой вариант: Подключить второй iLon10 и через один вести опрос, а через другой смотреть что творится сканером?

Забыл упомянть про длинну кабеля, точно пока сказать не могу, но ориентировочно общая длинна кабеля, думаю, не превышает 400 метров.

Проблема, на мой взгляд, в неподходящем кабеле.
Во вложенном файле рекомендуемые типы кабелей. Подходит МКЭШ под какой-нибудь?

AlekSir
Как минимум терминаторы вам надо поставить правильные.
Посмотрите приложенный файл.
Там - эшелоновские рекомендации по организации лон сетей. На странице 28 (3-6) дается схема терминатора для лон сетей, проложенных экранированными кабелями.
Нажмите для просмотра прикрепленного файла

К сожалению мы расплогаем только iLon10. А диагностировать сеть через имеющееся у нас усттройство не представляется возможным. Изначально предпологали что просто не умеем пользоваться ЛонСканером, а оказалось что iLon10 не поддержавает данный функционал. источник
Взять у кого-то на время другое устройство так же не можем т.к. устройства дорогостоящие и никто не держит их у себя просто так, только под заказ или уже под определенный проект. А вкладывать еще деньги для того что бы просто протестировать сеть никто не будет.

У вас подход студента. USB свисток стоит всего 160 баксов, разве это деньги?

Выимеете ввиду U10?
Если да, то я дам вам 50$ сверху если вы продадите мне U10 от Echelon за 160$. На дворе 2011 год, и цены июля 2009 уже как-то не котируются... Сейчас, судя по прайсу цена этого устройства несколько выше.

По делу:
Вчера ставил террминаторы (по схеме из документации рекомендуемой Himeg), вместе с рекомендуемым типом кабеля. После чего наблюдал примерно туже самую картину описанную выше. Причем соединял всего только 3 LGW находяшиеся в непосредственной близости (общая длинна шины кабеля не привышала двух метров). Опрашивал 4005 переменных с периодом 150 000мс. Ошибки начинают валиться при первом же опросе...
Что делать не понятно...
Хотим попробовать разделить пременные на группы и опрашивать по одной группе переменных, одну за другой.

AlekSir
Если честно, я до сих пор не совсем понимаю, какая у вас топология сети. С трех групп условно приходит по два двухжильных провода в шкаф с условной 4 группой шлюзов, шлюзы же соединяются в одну сторону с тремя группами, в другую - с ilon.10. Зачем тогда с удаленных трех групп устройств приходит по два конца кабеля с каждой, когда, кажется, достаточно одного?

Дело в том, что эшелон, например, настоятельно требует использовать разные типы терминаторов в шинной и свободной топологии (как и в случае с экранированными и неэкранированными кабелями). Я отослал Вас на терминатор для свободной топологии, он ставится в единственном экземпляре в одной, любой, точке сети. Если Вы пытаетесь коротким кабелем организовать шину, то тут уже потребуется терминатор с немного другой схемой (на след. странице мануала, который я выкладывал)

Именно этот мануал я выложил, опираясь на удачный опыт использования таких схем. Причем, в моих случаях все было довольно "чётко": нет терминатора - ошибки, подобные Вашим. Есть терминатор - все прекрасно работает.

А что ещё можно сделать в данной ситуации... Если есть возможность перемещать iLon.10 - попробуйте присоединиться напрямую к любой из удаленных групп лон-устройств (или вообще к одному устройству из группы), там, где в соединении не участвует никакой многожильный кабель с двумя обжатыми концами. Можно попробовать вообще без терминаторов, по идее, на коротких расстояниях (навроде Ваших двух метров) это не должно играть особой роли, ну, по крайней мере, увидите, что происходит со скоростью опроса переменных. Предварительно, разумеется, отключив эту группу от всего остального. Если будете ставить терминаторы, то нужно учесть топологию организуемой Вами тестовой сети и поставить правильные с т. зр. производителя iLON.10 терминаторы.